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Agenda 


Smart  Push,  Smart  Pull,  Sensor 
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Secure/Safe  (MLS) 
Infrastructure 


■  The  Vision:  Seamless  Data  Flow 
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■  Sensor  to  Weapon 

■  Information  Assurance  Requirements  of  the  Vision 

■  Design  Guidance 

■  Reference  Monitors 

■  Candidate  Technologies 

■  Multiple  Independent  Levels  of  Security 
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The  Vision:  Sensor  Fusion 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Each  sensor  type  reveals  different  information,  nominally 
(source:  wikipedia.org): 

■  Radar 

■  Sonar  and  other  acoustic 

■  Infra-red  /  Thermal  imagery 

■  HDTV  imagery 

■  Seismic  sensors 

■  Magnetic  sensors 

■  Electronic  Support  Measures  (ESM) 

■  Phased  Array 

■  Direct  fusion  from  disparate  sources  results  in  better  electronic 
information 

■  More  accurate 

■  More  complete 

■  More  dependable 


■  Indirect  fusion  merges  electronic  information  with  human  input, 
merging: 


■  ELINT: 

■  HUMINT: 

■  COMINT: 

■  SIGINT: 

■  IMINT: 


Electronic  Intelligence 
Human  Intelligence 
Communications  Intelligence 
Signals  Intelligence 
Imagery  Intelligence 
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Smart  Push,  Smart  Pull,  Sensor 

Sensor  Fusion 

to  Shooter  in  a  Multi-Level 

Secure/Safe  (MLS) 

Infrastructure 

■  Data  derived  from  Direct  Fusion  (contrived) 

■  What  is  it? 

■  T-72  Tank 

■  What  is  its  condition? 

■  Lightly  Damaged 

■  Where  is  it  now? 

■  Longitude  /  Latitude 

■  Where  has  it  been? 

■  Track 

■  Characteristics  of  the  Data 

■  Multiple  sensor  devices  on  a  surveillance  platform 

■  Sensor  devices  produce  giga-gobs  of  raw  data 

■  Real-time  transmission  of  all  raw  sensor  data  is  impractical 

■  Direct  Fusion  likely  to  be  performed  on  the  platform 

■  Raw  sensor  data  likely  to  be  TOP  SECRET 

■  Derived  data  likely  to  be  SECRET  NOFORN 

■  Data  derived  from  Direct  Fusion  shared  via  Smart  Push 
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MLS  Threat  Database 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Surveillance  platforms  use  SOA  to  populate  MLS  Web  Server 
database 

■  MLS  Web  Server  database  likely  to  be  SECRET  NOFORN 

■  Merged  with  data  about  each  threat  derived  from  Indirect  Fusion: 

■  Who  controls  it? 

■  What  is  its  threat  potential? 

■  What  are  its  intentions? 

■  Many  different  types  of  users  need  the  data: 

■  Cleared  US  Military 

■  At  various  levels 

■  Multiple  Communities  of  Interest 

■  Services,  Job  Titles,  etc. 

■  Uncleared  US  Military  in  vicinity  of  the  threat 

■  Cleared  coalition  partners 

■  At  various  levels 

■  Multiple  Communities  of  Interest  for  each  partner 

■  Canadian  Army  vs.  UK  Army  Vs.  UK  Special  Air  Service 

■  Uncleared  coalition  partners  in  vicinity  of  the  threat 
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Theoretical  Application: 

Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 

Command  and  Control 

Secure/Safe  (MLS) 

Infrastructure 

■  SOA  applications  query  the  database  searching  for  threats  that 
meet  certain  characteristics  Smart  Pull 

■  Threat  type 

■  Threat  nationality 

■  Proximity  to  Coalition  assets 

■  When  an  applicable  threat  is  found,  Command  and  Control 
personnel  are  notified  Smart  Push 

■  The  database  is  “Googled”  by  a  human  who  makes  the 
decision  to  prosecute  the  threat  Smart  Pull 

■  Humans  make  decisions  that  we  would  not  defer  to 
automation 
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Agile  Forces  Prosecute  Threat 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Command  and  Control  creates  an  ad-hoc  group  of  available 
assets  to  prosecute  the  threat 

■  Ad-hoc  task  force  requires  ad-hoc  networking  for  command 
and  control 

■  Task  force  comprised  of  assets  from  various  US  services  and 
coalition  partners 

■  Multiple  security  levels  and  communities  of  interest 

■  Data  shared  according  to  security  policy 

■  Downgraded 

■  Guarded 

■  Filtered 

■  After  threat  prosecution,  the  task  force  is  dissolved 
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Ad-hoc  Networking  Plumbing 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Fixed  Black  IP  addresses  for  Web  Servers 

■  Communications  via  Type-1  HAIPE  and/or  JTRS 

■  Type-1  Crypto  identifies  and  authenticates  registrant 

■  Also  identifies  and  authenticates  registrant’s  Domain 

■  Registrant  provides  its  own  Black  IP  address 

■  Also  can  provide  credentials,  geo-location,  and  capabilities 

■  Red  side  provides 

■  Available  services  list 

■  Red  IP  addresses  for  SOA  /  Web  portals 

■  Security  Policy  for  information  release  to  other  members  of 
the  ad-hoc  network  or  other  ad-hoc  networks 
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Agenda 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  The  Vision:  Seamless  Data  Flow 

■  Sensor  to  Shooter 

■  Sensor  to  Weapon 

■  Information  Assurance  Requirements  of  the  Vision 

■  Design  Guidance 

■  Reference  Monitors 

■  Candidate  Technologies 

■  Multiple  Independent  Levels  of  Security 
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Information  Assurance  Requirements 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Controlled  Information  Flow  to  users  in  multiple  Security 
Domains 

■  Controlled  Information  Flow  requires  trustworthy  enforcement 
of  appropriate  Security  Policies. 

■  Security  Policy  enforcement  must  be  trustworthy  so  that  the 
mission  is  not  compromised 

■  Even  more  important,  Information  Sharing  can’t  be  allowed 
to  endanger  the  Warfighters 

■  Information  Assurance  is  all  about  making  sure  that  the 
Warfighters’  systems  can’t  be  used  against  them. 

■  Trust  is  earned,  never  assumed 

■  Certification  and  Accreditation  are  the  ways  to  earn  Trust. 
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What  identifies  a  Security  Domain? 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Nationality 

■  US,  Canada,  UK,  etc 

■  Classification/Clearance 

■  SCI,  TS,  SECRET,  UNCLASSIFIED,  etc. 

■  Community  of  Interest 

■  Functional  Organization 

■  Geo-Location 

■  Iraq,  Afghanistan,  CONUS,  the  Pentagon,  etc. 

■  Safety 

■  Critical,  Non-critical,  etc. 
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Information  Flow  Control  Functions 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Cross  Domain  Server  components  that  enforce  the  Security 
Policy 

■  Downgraders 

■  Input:  Data  at  a  given  classification  level 

■  Output:  Data  at  a  lower  classification  level 

■  Rule  Sets 

■  Configured  for  each  data  stream 

■  Field  deletion  and  obfuscation 

■  Access  Control  Guards 

■  IBAC:  Identity  Based  Access  Control 

■  RBAC:  Role  Based  Access  Control 

■  Protocol  Specific  Access  Control 

■  CORBA/GIOP 

■  DDS 

■  HTTP 

■  etc. 
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Information  Flow  Control  (cont’d) 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Content  Guards 

■  Document  Type  Specific  Guarding  (notional) 


■  .doc 

■PPt 

.xls 

■  .pdf 

■jpg 

.mpeg 

■  .xml 

.avi 

.mov 

■  .html 

.mp3 

.ps/eps 

■  .tex 

.dvi 

.rtf 

Verify  no 

Deleted  Data  in  Document 

■  Verify  no  Hidden  Data  under  Overlay 

■  No  Non-displayed  Annotation  or  Comments 

■  Verify  Release  Markings 

■  “Dirty”  Word  Search 
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PDF  File  Guarding  Failure 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Italian  Shooting  Final  Report  (.pdf  Guarding  Failure) 


IN  CLASSIFIED 
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UNCLASSIFIED 


UNCLASSIFIED 


Smart  Pull  Information  Assurance 


■  “Googler”  Characteristics 

■  Nationality 

■  Clearance 

■  Job  Title 

■  Location 

■  Threat  Characteristics 

■  Classification  of  the  Threat(s) 

■  Location  of  the  Threat 

■  Security  Policies 

■  Releasability  of  Threat  Data 

■  Down  Grade  Policy 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 
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Security  Policy  Definition 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Requires  anticipation  of  the  unauthorized  events  that  the 
system  must  prevent 

■  e.g.,  No  SECRET  cleared  users  allowed  to  read  TOP 
SECRET  information 

■  System  Security  Policy  usually  consists  of  a  collection  of  sub¬ 
policies  which  define  the  security  services  offered  by  the 
system. 

■  Example  sub-policy:  User  Access  Control 

■  “A  correct  user  name,  password,  and  fingerprint  must  be 
entered  into  the  system  prior  to  user  access” 
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Communications  Security  Policy 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Notional  Security  Policy  for  Information  Flows 

■  PI  A:  There  shall  be  no  infiltration  of  data  among  flows 

■  PI  B:  There  shall  be  no  infiltration  of  data  within  flows 

■  P2A:  There  shall  be  no  exfiltration  among  flows 

■  P2B:  There  shall  be  no  exfiltration  within  flows 

■  P3:  There  shall  be  no  unauthorized  use  of  authorized  flows 

■  Example:  No  third  party  is  allowed  to  cause  information 
belonging  to  “A”  to  flow  to  “B”  even  if  the  security  policy 
allows  “A”  to  communicate  with  “B” 

■  Applicable  to  Security  Enforcing  components 

■  HAIPE 

■  JTRS 

■  PCS 

■  Etc. 


17 


Required  Levels  of  Assurance 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  High  Robustness  is,  in  general,  equivalent  to  Common  Criteria 
EAL6+ 

■  There  is  no  official  definition  of  High  Robustness  yet. 

■  Working  definition  in  SKPP  VO. 71  (draft) 

■  DCID  6/3  applies  to  all  entities  that  process,  store,  or 
communicate  intelligence  information 

■  An  information  system  operates  at  Protection  Level  5  when 
at  least  one  user  lacks  any  clearance  for  access  to  some  of 
the  information  in  that  system 

■  DO-1 78B  applies  to  software  for  airborne  systems  and 
equipment. 

■  Software  that  can  cause  a  catastrophic  failure  is  certified  at 
Level  A 

■  There  is  significant  overlap  and  synergy  among  these 
standards 
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The  Real  Hard  Problems 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Interdomain  Security  Policy  Management 

■  How  do  we  define  it? 

■  How  do  we  update  it? 

■  How  do  we  distribute  it 

■  Domain  Policy  Management 

■  How  do  we  include  a  new  actor  into  a  domain? 

■  How  do  we  revoke  privileges  of  an  actor? 

■  How  do  we  detect  and  exclude  a  compromised  actor? 

■  Threat-based  Domain  construction  and  destruction 

■  Multilevel 

■  Multinational 

■  Multiple  COIs 
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The  Real  Hard  Problems  (cont’d) 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Transparency 

■  Warfighters  are  supposed  to  expend  their  resources  on 
fighting  wars,  not  enforcing  security  policies 

■  If  it  is  too  hard  to  follow,  nobody  will  follow  it 

■  “Get  the  job  done”  attitude 

■  If  it  is  too  hard  to  administer,  nobody  will  administer  it 

■  Security  can  be  compromised 
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Agenda 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  The  Vision:  Seamless  Data  Flow 

■  Sensor  to  Shooter 

■  Sensor  to  Weapon 

■  Information  Assurance  Requirements  of  the  Vision 

■  Design  Guidance 

■  Reference  Monitors 

■  Candidate  Technologies 

■  Multiple  Independent  Levels  of  Security 
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Overall  System  Security  Policy 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Bell-LaPadula  to  focus  on  Confidentiality 

■  Read  Down,  Write  Up 

■  Protects  against  unauthorized  disclosure 

■  Biba  to  focus  on  Integrity 

■  Read  Up,  Write  Down 

■  Protects  against  unauthorized  modification 

■  Other  security  policies: 

■  Brewer-Nash  (access  control) 

■  Information  flow  model  provides  controls  to  mitigate 
conflict  of  interest 

■  Clark-Wilson  (integrity) 

■  Well  formed  transactions  transition  system  from  one 
secure  state  to  another 

■  Graham-Denning  (rights) 

■  Define  rights  on  how  subjects  execute  security 
functions  on  objects 
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Unauthorized  Events 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Identify  the  unauthorized  events  that  the  system  must  prevent 

■  Typically,  systems  must  protect  against: 

■  Unauthorized  Disclosure 

■  Confidentiality 

■  Unauthorized  Modification 

■  Integrity 

■  Unauthorized  Access 

■  Access  Control 

■  Masquerade  or  Replay 

■  Authentication 

■  Denial  of  Transmission  or  Reception 

■  Non-repudiation 

■  Denial  of  Service 

■  Availability 
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Derived  System  Requirements 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Input:  System  Security  Policy 

■  Input:  Unauthorized  Events 

■  Use  these  inputs  to  derive  a  list  of  requirements  which  the 
system  must  meet 

■  Result:  A  written  System  Requirements  Document  (SRD) 

■  When  dealing  with  classified  data,  seek  NSA  IAD  guidance 

■  Engage  them  EARLY 

■  Engage  them  OFTEN 
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Smart  Push,  Smart  Pull,  Sensor 

Step  1:  Assess  Information  Value 

to  Shooter  in  a  Multi-Level 

Secure/Safe  (MLS) 

Infrastructure 

■  Consult  the  Information  Assurance  Technical  Framework 

■  Best  practices  document,  available  on  http://iatf.net 

■  Value  assessed  by  evaluation  the  consequences  of  security 
policy  violation  with  respect  to: 

■  Security 

■  Safety 

■  Financial  Posture 

■  Infrastructure 

■  The  IATF  identifies  five  levels: 

■  VI:  Negligible  effect 

■  V2:  Minimal  Damage 

■  V3:  Some  Damage 

■  V4:  Serious  Damage 

■  V5:  Exceptionally  Grave  Damage 
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Smart  Push ,  Smart  Pull,  Sensor 

Step  2:  Determine  Threat  Levels 

to  Shooter  in  a  Multi-Level 

Secure/Safe  (MLS) 

Infrastructure 

■  Best  practices  also  in  the  IATF 

■  Threats  are  ranked  by  assessing: 

■  Capability 

■  Resources 

■  Motivation 

■  Risk  Willingness 

■  The  IATF  identifies  seven  levels: 

■  T 1 :  Inadvertent  or  accidental  events 

Tripping  over  a  power  cord 

■  T2:  Minimal  resources  -  willing  to  take  little  risk 

Passive,  casual  eavesdropper 

■  T3:  Minimal  resources  -  willing  to  take  significant  risk 

Unsophisticated  hacker 

■  T4:  Moderate  resources  -  willing  to  take  little  risk 

Organized  crime,  sophisticated  hacker, 
international  corporations 

■  T5:  Moderate  resources  -  willing  to  take  significant  risk 

International  terrorists 

■  T6:  Abundant  resources  -  willing  to  take  little  risk 

Well  funded  national  laboratory, 
nation-state,  international  corporation 

■  T7:  Abundant  resources  -  willing  to  take  significant  risk 

Nation-states  in  time  of  crisis 
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Smart  Push ,  Smart  Pull,  Sensor 

Step  3:  Protection  Mechanisms 

to  Shooter  in  a  Multi-Level 

Secure/Safe  (MLS) 

Infrastructure 

■  Confidentiality 

■  Encryption  algorithms 

■  Integrity 

■  Hashing  algorithms 

■  Access  Control 

■  Identification  and  Authentication 

■  Authentication 

■  Certificates 

■  Non-repudiation 

■  Digital  Signatures 

■  Availability 

■  Redundancy 
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Step  4:  Strength  and  Assurance  Level 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  From  the  IATF,  Strength  of  Mechanism  and  Assurance  Level 
mapped  to  Information  Value  and  Threat  Level 


Information 

Threat  Levels 

Value 

T1 

T2 

T3 

T4 

T5 

T6 

T7 

VI 

SML1 

EAL1 

SML1 

EAL1 

SML1 

EAL1 

SML1 

EAL2 

SML1 

EAL2 

SML1 

EAL2 

SML1 

EAL2 

V2 

SML1 

EAL1 

SML1 

EAL1 

SML1 

EAL1 

SML2 

EAL2 

SML2 

EAL2 

SML2 

EAL3 

SML2 

EAL3 

V3 

SML1 

SML1 

SML1 

SML2 

SML2 

SML2 

SML2 

EAL1 

EAL2 

EAL2 

EAL3 

EAL3 

EAL4 

EAL4 

V4 

SML2 

EAL1 

SML2 

EAL2 

SML2 

EAL3 

SML3 

EAL4 

SML3 

EAL5 

SML3 

EAL5 

SML3 

EAL6 

V5 

SML2 

SML2 

SML3 

SML3 

SML3 

SML3 

SML3 

EAL2 

EAL3 

EAL4 

EAL5 

EAL6 

EAL6 

EAL7 
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Step  5:  Principle  of  Least  Privilege 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Architecture  Policy:  INFOSEC  boundaries  shall  be  designed 
using  the  Principle  of  Least  Privilege 

■  Principle  of  Least  Privilege:  Each  subject  is  granted  only  the 
most  restrictive  set  of  privileges  (or  clearance)  needed  to 
perform  its  authorized  tasks 

■  Minimum  memory  footprint 

■  Only  what  is  needed  and  nothing  more 

■  Minimum  hardware  features 

■  Smallest  capability  set  and  nothing  more 

■  Minimum  invocation  of  rights 

■  Only  necessary  privileges  only  when  needed 

■  Maximum  separation 

■  Necessary  data  disclosed  and  nothing  more 
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Smart  Push ,  Smart  Pull,  Sensor 

Step  6:  Utilize  the  Common  Criteria 

to  Shooter  in  a  Multi-Level 

Secure/Safe  (MLS) 

Infrastructure 

■  Utilize  the  Functional  Requirements  in  Part  2  to  help  define  the 
system  and  meet  the  System  Requirements  Document 

■  Utilize  the  Assurance  Requirements  in  Part  3 

■  Configuration  Management 

■  Delivery  and  Operation 

■  Development 

■  Guidance  Documents 

■  Testing 

■  Life  Cycle  Support 

■  Vulnerability  Assessment 

■  Maintenance  of  Assurance 
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Software  Development 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Use  a  defined/structured  process  (e.g.,  SEI/CMMI) 

■  Produce  software  that  does  only  its  intended  task  and  is 
evaluatable 

■  NSA  requires  at  least  CMMI  Level  3 

■  For  software  that  is  not  security  enforcing  or  security  relevant 

■  Develop  the  code  with  good  quality  control  techniques,  in 
small,  well-structured  units,  and  thoroughly  test  it 
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Trusted  Software  Development 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Code  that  is  Security  Enforcing  or  Security  Relevant 

■  Develop  the  code  from  an  abstract  finite  state  machine  (when  it 
makes  sense) 

■  Use  formal  tools  (e.g.  model  checkers)  to  evaluate  the  state 
machine  and  other  critical  code 

■  Develop  a  mapping  between  the  state  machine  and  the  code 

■  Boot  process,  with  digitally  signed  copies  of  ALL  software 
running  on  the  system,  should  be  stored  in  the  system  on  ROM 
and  protected  accordingly 

■  Meet  ALL  Non-Trusted  development  requirements 
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Agenda 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  The  Vision:  Seamless  Data  Flow 

■  Sensor  to  Shooter 

■  Sensor  to  Weapon 

■  Information  Assurance  Requirements  of  the  Vision 

■  Design  Guidance 

■  Reference  Monitors 

■  Candidate  Technologies 

■  Multiple  Independent  Levels  of  Security 
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Reference  Monitor  Characteristics 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Common  Criteria  Definition  (Version  2.2,  Part  1,  page  14) 

■  The  concept  of  an  abstract  machine  that  enforces  TOE 
access  control  Policies 

■  The  enforcement  point  for  the  Security  Policy 

■  The  Reference  Monitor  is  not  always  a  software  module 

■  The  Reference  Monitor  is  an  abstraction 

■  The  best  Reference  Monitor  is  no  Reference  Monitor 

■  Because  the  design  of  the  system  itself  makes  violation  of 
the  Security  Policy  impossible 

■  (e.g.,  separation  by  air  gap) 

■  It  isn’t  always  practical,  affordable,  or  achievable  to  design 
systems  that  way 

■  Potentially  user  unfriendly 

■  Cost 

■  Size,  Weight,  and  Power 
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Reference  Monitors  Must  be  NEAT 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


To  be  effective,  Security  Policy  Enforcement  must  be: 


N 

E 

A 


A/on-bypassable 

■  Security  functions  cannot  be  circumvented 

Evaluatable 

■  Security  functions  are  small  enough  and  simple  enough  for 
mathematical  verification 

Always  Invoked 

■  Security  policy  is  enforced  each  and  every  time 

Tamperproof 

■  Subversive  or  errant  code  cannot  alter  the  security  data  or 
functions 


Reference  Monitor  Protection 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Reference  Monitor  is  the  heart  of  the  TOE  Security  Function  (TSF) 

■  TSF:  TOE  Security  Function 

■  TOE:  Target  of  Evaluation 

■  Common  Criteria  class  FPT:  Protection  of  the  TSF 

■  Decomposed  into: 


AMT 

Underlying  abstract  machine  test 

RPL 

Replay  detection 

FLS 

Fail  Secure 

RVM 

Reference  mediation 

ITA 

Availability  of  exported  TSF  data 

SEP 

Domain  separation 

ITC 

Confidentiality  of  exported  TSF  data 

SSP 

State  synchrony  protocol 

ITI 

Integrity  of  exported  TSF  data 

STM 

Time  stamps 

ITT 

Internal  TSF  data  transfer 

TDC 

Inter-TSF  data  consistency 

PHP 

TSF  physical  protection 

TRC 

Internal  TOE  TSF  data  replication 
consistency 

RCV 

Trusted  Recovery 

TST 

TSF  self  test 
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Agenda 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  The  Vision:  Seamless  Data  Flow 

■  Sensor  to  Shooter 

■  Sensor  to  Weapon 

■  Information  Assurance  Requirements  of  the  Vision 

■  Design  Guidance 

■  Reference  Monitors 

■  Candidate  Technologies 

■  Multiple  Independent  Levels  of  Security 
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Monolithic  Security  Kernel 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  All  security  is  policy  is  performed  by  the  security  kernel 

■  Originally  for  performance  reasons 

■  No  other  was  to  ensure  enforcement  is  non-bypassable 

■  As  security  policy  becomes  more  complex: 

■  Code  grows  in  security  kernel 

■  Certification  efforts  become  unmanageable 

■  Evaluatability  of  kernel  code  decreases 

■  Maintainability  of  kernel  code  decreases 

■  Policy  decisions  can  be  based  on  incomplete  or 
unauthenticated  information 
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Monolithic  Security  Kernel 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


Monolithic  Applications 


Monolithic 

Application 

Extensions 


User 

Mode 


Fault  Isolation 


Periods  Processing 


Kernel 


Network  I/O 


Auditing 


Monolithic  Kernel 


Information  Flow 
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5 


Data  isolation 


% 


0® 


;N|'( 


Ge 


6^ 


Privilege 

Mode 
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Smart  Push,  Smart  Pull,  Sensor 

Fail-first,  Patch-later 

to  Shooter  in  a  Multi-Level 

Secure/Safe  (MLS) 

Infrastructure 

■  Most  commercial  computer  security  architectures 

■  The  result  of  systems  software  where  security  was  an  afterthought 

■  Operating  systems 

■  Communications  architectures 

■  Reactive  response  to  problem 

■  Viruses,  Worms,  and  Trojan  Horses 

■  Hackers  and  Attackers 

■  Problems  are  only  addressed  after  the  damage  has  been  done 

■  Inappropriate  approach  for  mission  critical  systems 

■  Does  not  safeguard  information  or  the  warfighter 

■  Proactive  measures  are  required  to  prevent  damage 
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High  Assurance  Monolithic  Kernel? 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


Monolithic  Applicati 


Fault  Isolation 


Periods  Processing 


Kernel 


MLS/CDS  Requires 
Systems  Evaluatable 
At  High  Assurance! 


onolithic 
Application 
Extensions 


ithic  Kernel 


Data  isolation 


% 


d^5 


User 

Mode 


Privilege 

Mode 
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Privileged  Mode  Protocol  Processing 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


What  happens  when  network  headers 
are  processed  in  privilege  mode? 
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Breeding  Ground  for  Internet  Wildlife 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


Wild  Creatures  of  the  Net:  Worms,  Virus, . . . 
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NetTop 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Developed  by  NSA  “R”  Group  for  internal  use,  later  licensed  for 
unlimited  distribution  by  HP  and  TCS 

■  Assembled  from  readily  available  software  components 

■  Device  drivers  from  SELinux 

■  Separation  from  VMware® 

■  Virtual  machines  run  Windows®  or  Linux® 

■  Virtual  machines  communicate  via  virtual  NICs 

■  Originally  approved  by  the  NSA  for  internal  use  to  provide 
separation  of  TOP  SECRET  from  SECRET  without  respect  to 
compartments  or  need  to  know,  only  for  users  with  TOP 
SECRET  clearance 

■  Intended  to  connect  internal  NSANet  (TS)  to  SIPRNET  (S) 
for  users  with  TS  clearance 

■  Accredited  by  NSA  to  run  in  DCID  6/3  PL4  environments 

■  Extends  original  certification  to  allow  users  with  Secret 
clearances 
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NetTop  Architecture 


Smart  Push ,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


VM  1 

VM  2 

VM  10 

Top  Secret 

Secret 

UNCL 

Virtual  Hardware 

Virtual  Hardware 

r 

:  Virtual  Hardware 

Other  DD’s 


Linux  Kernel 


NIC  Device  Driver 


Host  OS 
SELinux 


VMWare 

Virtual 

Machine  (VM) 
Monitor  (VMM) 


'BIOS-Runtime 


r  w 

NIC 

NIC 

BIOS-Flash  (Boot  Loader  /  BIT) 


Host  Computer  Hardware 


Blue  =  Ring  0 
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NetTop  Characteristics 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Readily  available  on  generic  PC  hardware 

■  A  desktop  solution,  no  plans  for  embedded  support 

■  Not  applicable  to  weapon  systems  or  platforms 

■  Meets  NSTISSP-1 1  validation  requirements 

■  Not  certified  via  CCEVS  (NIAP) 

■  CCRA  not  applicable 

■  Applicable  to  low  threat  environments 

■  Trusted  people  in  secure  facilities 

■  Provides  a  moderately  robust  level  of  separation 

■  COTS  components  do  not  meet  least  privilege  high 
robustness  design  requirements 
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Agenda 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  The  Vision:  Seamless  Data  Flow 

■  Sensor  to  Shooter 

■  Sensor  to  Weapon 

■  Information  Assurance  Requirements  of  the  Vision 

■  Design  Guidance 

■  Reference  Monitors 

■  Candidate  Technologies 

■  Multiple  Independent  Levels  of  Security 
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Multiple  Independent  Levels  of 

Smart  Push ,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 

Security  (MILS) 

Secure/Safe  (MLS) 

Infrastructure 

■  Three  distinct  layers  (John  Rushby,  PhD) 

"  Separation  Kernel 

■  Separate  process  spaces  (partitions) 

■  Secure  transfer  of  control  between  partitions 

■  Really  small:  4K  lines  of  code 

■  Middleware 

■  Application  component  creation 

■  Provides  secure  end-to-end  inter-object  message  flow 

■  Device  Drivers,  File  Systems,  Network  Stacks, 
CORBA,  DDS,  Attestation,  ... 

■  Applications 

■  Implement  application-specific  security  functions 

■  Firewalls,  Cryptomod,  Guards,  Mapplet  Engine,  CDS, 
Multi-Nation  Web  Server,  etc. 


48 


The  MILS  Layered  Architecture 


Separation  Kernel 

■  The  only  code  that  runs  in  privileged 
mode 

■  Microprocessor  Based 

■  Multi-Core  Time  and  Space 
Multi-Threaded  Partitioning 

■  Data  Isolation 

■  Inter-partition  Communication 

■  Periods  Processing 

■  Resource  Sanitization 

■  Minimum  Interrupt  Servicing 

■  Semaphores 

■  Multi-Core  Synchronization 
Primitives 

■  Timers 

And  nothing  else! 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


MILS  Middleware 

■  Traditional  RTOS  Services 

■  Device  Drivers 

■  File  Systems 

■  Token  and  Trusted  Path 

■  Traditional  Middleware 

■  CORBA  (Distributed  Objects) 

■  Data  Distribution  (Pub-Sub) 

■  Web  Services 

■  Partitioning  Communication  System 
(PCS) 

■  Global  Enclave  Partition  Comm 

■  TCP,  UDP,  Rapid-IO,  Firewire, 
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The  Whole  Point  of  MILS 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


Really  very  simple: 

■  Dramatically  reduce  the  amount  of 
security  critical  code 

So  that  we  can 

■  Dramatically  increase  the  scrutiny  of 
security  critical  code 

To  make 

■  Development,  certification,  and  accreditation  more 
practical,  achievable,  and  affordable. 
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Breeding  Ground  for  Internet  Wildlife 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


Wild  Creatures  of  the  Net:  Worms,  Virus, . . . 
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MILS  Paradigm  Shift 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


Under  MILS,  network  header  and 
privilege  mode  processing  are  separated 
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MILS  Architecture  Evolution 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 
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The  MILS  Architecture 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 
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Guest  OS  Architecture 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


t 


Processor 
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Distributed  Security  Requirements 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Extend  single  node  security  policy  enforcement  to  multiple 
nodes 

■  Do  not  add  new  threats  to  data  Confidentiality  or  Integrity 

■  Enable  distributed  Reference  Monitors  to  be  NEAT 

■  Optimal  inter-node  communication 

■  Minimizing  added  latency  (first  byte) 

■  Minimizing  bandwidth  reduction  (per  byte) 

■  Fault  tolerance 

■  Security  infrastructure  must  have  no  single  point  of  failure 

■  Security  infrastructure  must  support  fault  tolerant 
applications 
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Partitioning  Communications  System 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Part  of  MILS  Middleware 

■  Responsible  for  all  communication  between  MILS  nodes 

■  Specific  Requirements: 

■  Strong  Identity 

■  Nodes,  applications,  and  application  instances 

■  Separation  of  Levels/Communities  of  Interest 

■  Secure  Configuration  of  all  Nodes  in  Enclave 

■  Bandwidth  provisioning  &  partitioning 

■  Secure  Clock  Synchronization 

■  Suppression  of  Covert  Channels 

■  Network  resources:  bandwidth,  hardware  resources,  buffers 

■  Secure  Loading:  signed  partition  images 
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Inter-node  Communication 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 
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Partitioning  Security  Policy 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Notional  Security  Policy  for  Information  Flows 

■  PI  A:  There  shall  be  no  infiltration  of  data  among  flows 

■  PI  B:  There  shall  be  no  infiltration  of  data  within  flows 

■  P2A:  There  shall  be  no  exfiltration  among  flows 

■  P2B:  There  shall  be  no  exfiltration  within  flows 

■  P3:  There  shall  be  no  unauthorized  use  of  authorized  flows 

■  Example:  No  third  party  is  allowed  to  cause  information 
belonging  to  “A”  to  flow  to  “B”  even  if  the  security  policy 
allows  “A”  to  communicate  with  “B” 
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Partitioning  Security  Policy 


TS 


TS/S 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


TS 


TS/S 
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PCS  is  Trusted  Plumbing 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  PCS  assumes  the  network  can’t  be  trusted 

■  Leverage  COTS  stacks,  NICs,  media,  switches,  and  routers 

■  PCS  provides  trusted  data  flow  among  distributed  applications 
and  guards 

■  Code  that  was  typically  duplicated  from  partition  to  partition 

■  Access  guards  and  data  guards  can  be  tightly  focused  on  the 
data  owner’s  specific  requirements 

■  Trusted  data  flow  enables  higher  assurance 

■  Smaller  code  body 

■  Simpler  logic 

■  Formal  methods  more  practical 
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Air  Gap  Works  But.... 

Smart  Push ,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 

Costly,  Inflexible,  &  Awkward 

Secure/Safe  (MLS) 

Infrastructure 

UNCLASSIFIED 


ETHERNET 
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Combining  Levels  On  Medium 
Assurance  Platforms  Is  Unsafe 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


Vulnerabilities 


MILS  Separation  Kernels 
Counter  Most  Internal  Threats 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


ETHERNET 


UNCLASSIFIED 

APPLICATION 


Vulnerabilities 
>  Reduced  Vulnerabilities 


PCSexpress  Completes  MILS 
Separation  Kernel 
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SECRET 

APPLICATION 


TCP/IP 


Vulnerabilities 
>  Reduced  Vulnerabilities 


Guards  Still  Needed  for 

Smart  Push ,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 

Intra-level  Threats 

Secure/Safe  (MLS) 

Infrastructure 

Multiple  Vulnerabilities 


Data  Vulnerabilities 


Use  Cases:  Definition  of  Terms 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Trusted  Transport 

■  Communications  system  can  be  trusted  to  maintain  separation  by 
level  and  Community  of  Interest 

■  Untrusted  Transport 

■  Communications  system  cannot  be  trusted  to  maintain  separation 
by  level  and  Community  of  Interest 

■  Gray  Sky 

■  Threats  to  communications  confidentiality  are  acceptably  low 

■  Example:  Front  to  back  of  an  airplane  or  submarine;  within  an 
FCS  tank 

■  Blue  Sky 

■  Threats  to  communications  confidentiality  are  unacceptably  high 

■  Example:  Radio  transmission;  the  Internet 
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Trusted  Transport,  Gray  Sky 
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Untrusted  Transport,  Gray  Sky 


Top  Secret 
Application 

_ 

PCS  - 

Secret 

Application 
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Separation  Kernel 

Gigabit  Ethernet 


>  Node  Authentication 

*  Application  Authentication 
i  •  Flow  Authorization 

*  Rate  Management 
■  Encryption  for  Separation 
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Untrusted  Transport,  Blue  Sky 


Top  Secret , 
Application 
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■  Node  Authentication 

■  Application  Authentication 

■  Flow  Authorization 

■  Rate  Management 

■  Encryption  for  Separation 

■  Covert  Channel  Suppression 
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Trusted  Transport,  Blue  Sky 
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Real-time  MILS  CORBA 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


■  Real-time  CORBA  can  take  advantage  of  PCS  capabilities 

■  Real-time  CORBA  +  PCS  =  Real-time  MILS  CORBA 

■  Additional  application-level  security  policies  are 
enforceable  because  of  MILS  SK  and  PCS  foundation 

■  Real-time  MILS  CORBA  represents  a  single  enabling 
application  infrastructure 
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Smart  Push ,  Smart  Pull,  Sensor 

Real-time  MILS  CORBA  (cont.) 

to  Shooter  in  a  Multi-Level 

Secure/Safe  (MLS) 

Infrastructure 

■  Can  address  key  cross-cutting  system  requirements 

■  MILS-based  distributed  security 

■  High-assurance 

■  High-integrity  (safety  critical  systems) 

■  Real-time 

■  Fixed  priority 

■  Dynamic  scheduling 

■  Distributed  object  communications 

■  Predictable 

■  Low  latency 

■  High  bandwidth 
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Smart  Push,  Smart  Pull,  Sensor 

RT  CORBA  &  MILS  Synergy 

to  Shooter  in  a  Multi-Level 

Secure/Safe  (MLS) 

Infrastructure 

■  Synthesis  yields  an  unexpected  benefit 

■  Flexibility  of  Real-time  CORBA  allows  realization  of  MILS 
protection 

■  MILS  is  all  about  location  awareness 

■  Well  designed  MILS  system  separates  functions  into  separate 
partitions 

■  Takes  advantage  of  the  MILS  partitioning  protection 

■  Real-time  CORBA  is  all  about  location  transparency 

■  The  application  code  of  a  properly  designed  distributed 
system  built  with  Real-time  CORBA  will  not  be  aware  of  the 
location  of  the  different  parts  of  the  system. 

■  CORBA  flexibility  allows  performance  optimizations  by 
rearranging  what  partitions  each  system  object  executes  in. 

■  System  layout  can  be  corrected  late  in  the  development  cycle 

■  Combination  of  MILS  and  Real-time  CORBA  allows  system 
designer  to 

■  Rearrange  system  functions  to  take  advantage  of 
protection  without  introducing  new  threats  to  data 
confidentiality  and  integrity 
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System  Architecture  with  PCS 


Application 

% 

CORBA,  DDS, 
Web,  etc. 

MILS  Socket  Lib 


PCS 

/ 


Smart  Push,  Smart  Pull,  Sensor 
to  Shooter  in  a  Multi-Level 
Secure/Safe  (MLS) 
Infrastructure 


Network 
Protocols  & 
Drivers 
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CCEVS: 

CCRA: 

CMMI: 

COI: 

COMINT: 

CONUS: 

CORBA: 

DCID: 

DDS: 

EAL: 

ELINT: 

GIOP: 

HAIPE: 

HTTP: 

HUMINT: 

IAD: 

IATF: 

IBAC: 

IMINT: 

JTRS: 

MILS: 

MLS: 

NSA: 

PCS: 

RBAC: 

SEI: 

SIGINT: 

SKPP: 

SOA: 

SRD: 

TOE: 

TSF: 

Common  Criteria  Evaluation  Scheme 

Common  Criteria  Recognition  Arrangement 
Capability  Maturity  Model  Integration 

Community  of  Interest 

Communications  Intelligence 

Continental  United  States 

Common  Object  Resource  Broker  Architecture 
Director  of  Central  Intelligence  Directive 

Data  Distribution  Service 

Evaluation  Assurance  Level 

Electronic  Intelligence 

General  Inter-Orb  Protocol 

High  Assurance  Internet  Protocol  Equipment 
Hypertext  Transfer  Protocol 

Human  Intelligence 

Information  Assurance  Directorate 

Information  Assurance  Technical  Framework 
Identity  Based  Access  Control 

Imagery  Intelligence 

Joint  Tactical  Radio  System 

Multiple  Independent  Levels  of  Security 
Multi-Level  Security/Safety 

National  Security  Agency 

Partitioning  Communications  System 

Role  Based  Access  Control 

Software  Engineering  Institute  (Carnegie  Mellon) 
Signals  Intelligence 

Separation  Kernel  Protection  Profile 

Services  Oriented  Architecture 

System  Requirements  Document 

Target  of  Evaluation 

TOE  Security  Functions 
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